In the Mobile IPv6 protocol (standardized by the IETF), a roaming mobile node is responsible for informing its home agent and correspondent nodes of its current care-of-address. Whenever a mobile node changes its care-of-address, it sends a Binding Update message to its home agent, performs a Return Routability procedure with the correspondent nodes, and finally sends Binding Updates to the correspondent nodes. During the time when the mobile node has already moved but the bindings have not been updated, packets destined for the mobile node continue to be delivered to the old care-of-address and are lost by default.
In a typical situation, the mobile node, the home agent and/or (at least some of) the correspondent nodes may be far from each other, e.g. on different continents. Consequently, the communication latency between the nodes may be high, typically at least tens of milliseconds and often in the order of 100 ms or more. Due to the Return Routability procedure, it takes 1.5 round trip times to update the binding at the correspondent nodes, and at least 0.5 round trip time to update the binding at the home agent. Given these latencies, the delay in updating the bindings can be up to a few hundreds milliseconds or even longer. While such a delay and packet loss may well be acceptable to some applications, it is clearly unacceptable to others such as conversational multimedia and other real time applications.
To overcome the packet loss problem, it is possible to forward the packets destined for the old care-of-address to the new care-of-address. This function can be performed by the previous default router of the mobile node. One possible way of setting up the forwarding procedure is specified by the IETF mobile IP Working Group [Koodli, R., “Fast Handovers for Mobile IPv6”, draft-ietf-mobileip-fast-mipv6-06 (work in progress), March 2003]. Packet forwarding can be set up before the handover occurs, but only if the mobile node knows the identity of the new access router and is able to pass a corresponding identifier to the previous default router. Otherwise the forwarding must be set up after handover and that is likely to result in some packet loss.
Any solution to this problem must be secure and simple. State creation should be avoided where ever possible as, among other disadvantages, creating states at the network is always a potential security risk. Any solution must also be scalable. Explicit security infrastructures, such as AAA or PKI should be avoided, since these are likely to create scalability bottlenecks.